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ABSTRACT 


'  SHAPE  Technical  Center  has  developed  the  Transitional  Information 
Distribution  Experiment  (TIDE)  to  study  the  storage,  handling  and  display  of 
information  in  SHAPE  HQ.  This  report  comments  on  some  human  factors 
aspects  of  the  Teletide  Graphics  System  (Version  2.0),  the  part  of  TIDE  used 
to  create,  manipulate  and  display  information  on  maps.  Relevant  portions  of 
DCIEM  research  plans  are  briefly  described.  , 


I 


/ 
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GENERAL 


The  Transitional  Information  Distribution  Experiment  (TIDE)  is  a  sys¬ 
tem  developed  by  SHAPE  Technical  Center  (STC)  to  study  the  storage,  han¬ 
dling  and  display  of  information  in  the  SHAPE  HQ.  The  system  design  has 
been  derived  from  a  careful  analysis  of  the  military  user’9  requirements  for 
information.  Its  success  is  due  in  large  part  to  a  philosophy  of  reasonable, 
attainable  design  goals,  an  iterative  approach  to  design  which  permits  con¬ 
stant  feedback  from  the  user,  and  sensitivity  to  the  user's  need  for  an  acces¬ 
sible,  easily-learned  system.  The  result  is  one  of  the  few  computer-based 
information  systems  actually  being  used  by  land  forces  personnel.  It  is  also 
the  only  one  using  digitized  maps  for  presenting  the  ground  force  situation. 
Its  success  is  attested  by  the  fact  that  military  users  requested  that  it 
remain  in  operation  beyond  the  experimental  testing  periods.  The  system 
specifications  that  will  result  from  TIDE  will  be  implemented  as  part  of  Project 
85,  an  upgrading  of  SHAPE'S  command  and  control  systems. 

Successful  as  TIDE  is.  there  remain  some  areas  in  which  it  might  be 
improved.  The  following  are  comments  on  the  user  interface  to  the  Teletide 
Graphics  System,  the  component  of  the  TIDE  system  which  permits  display 
creation,  update  and  manipulation.  They  are  based  on  DCIEM’s  experience 
with  the  system  over  the  period  9-13  June,  1981,  on  the  STC  working  paper 
entitled  "Teletide  Graphics  System  User  Manual,  Version  2.0"  (Ref.  1),  and  on 
conversations  with  STC  personnel.  Since  the  documentation  on  which  these 
comments  are  based  was  in  draft  form,  certain  misconceptions  about  system 
operation  may  have  resulted.  These  are  noted  where  suspected.  These  com¬ 
ments  assume  that  the  reader  is  familiar  with  the  TIDE  system  at  least  gen¬ 
erally  and  has  access  to  the  STC  Teletide  User  Manual. 

To  assist  analysis,  a  set  of  flow  diagrams  was  drawn  up,  reflecting  the 
sequence  of  the  Teletide  dialogue  as  described  in  the  manual.  These  are 
presented  in  Figure  1. 

The  remarks  are  divided  into  four  sections: 

1)  -  Comments  on  the  human  engineering  of  the  interface  to  the  menu 
system,  including  inconsistencies  which  have  probably  occurred  as  a 
result  of  the  lengthy  time  span  of  Teletide  development; 

2)  -  Teletide  enhancements  that  could  be  included  as  part  of  the 
specifications  for  Project  85; 

3)  -  More  general  remarks  on  the  interaction  technique  used  and  some 
alternatives  that  could  be  considered  for  future  systems; 

4)  -  Some  human  factors  issues  that  will  arise  in  future  systems  when 
maps  are  created  and  manipulated  by  the  military  user. 
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TELETIDE  DIALOGUE 


Display  pages  and  overlays 

There  are  inconsistencies  in  the  terminology  and  labelling  used  to 
describe  a  display  ’’screenful"  of  information  created  by  the  user.  In  most 
usages,  a  "display  page”  consists  of  a  background  map,  an  overlay  of  military 
symbology  and  a  descriptive  frame  with  title,  classification,  "as  of'  time  and 
name  (e.g..  AS01).  In  such  a  case,  it  could  also  be  referred  to  as  a  situation 
display.  Alternatively,  a  display  page  could  consist  of  a  plain  colour  back¬ 
ground  with  superimposed  alphanumeric  text  plus  the  descriptive  frame.  In 
many  instances  in  the  Teletide  dialogue,  the  word  "overlay"  is  used  as  a 
synonym  for  display  page,  the  name  of  the  page  being  synonymous  with  the 
name  of  the  overlay.  This  causes  confusion.  For  instance,  the  main  directory 
(described  in  section  2.1  of  the  user’s  manual)  is  called  an  "OVERLAY  DIREC¬ 
TORY",  but,  in  fact,  lists  display  pages.  Similarly,  the  DISPLAY  command  asks 
for  an  OVERLAY  NAME,  but  presents  display  pages  on  the  TV  screen. The 
CREATE  command  asks  for  a  DISPLAY  NAME  (entered  as  @@##),  and  then 
refers  to  the  creation  of  OVERLAY  ®@##.  The  REMOVE  command  may  also 
confuse  the  user  since  it  is  not  clear  whether  he  is  erasing  just  the  military 
symbology,  or  the  associated  map  as  well.  (A  better  term  might  be  CLEAR, 
since  the  user  is  not  removing  the  display  page,  but  clearing  it  for  future 
use.)  Similarly  when  the  user  ATTACHs  or  ADDs  information  to  am  existing 
display,  is  it  just  the  overlay  portion  that  is  added,  or  the  entire  display  (i.e., 
what  happens  when  the  maps  are  different?). 

It  is  not  easy  to  resolve  these  discrepancies.  Perhaps  a  clear 
definition  of  the  terminology  (in  the  user  introduction  to  the  system)  as  well 
as  careful  attention  to  its  usage  in  the  dialogue  will  be  sufficient.  For  exam¬ 
ple,  instead  of  referring  to  OVERLAY  ®@##,  the  phrase  used  should  be  DISPLAY 
PAGE  FOR  OVERLAY  ©O##. 


Flow  of  control 

The  flow  of  control  within  the  menu  system  is  unclear  at  certain 
points,  particularly  at  the  exits  within  the  menu  (refer  to  Figure  1).  In  man)” 
cases  these  problems  may  be  due  to  incomplete  documentation.  The  following 
trouble  points  were  noted: 

1)  -  It  is  not  clear  where  the  control  goes  when  the  user  exits  prema¬ 

turely  (by  typing  XX)  from  LG  or  MP  in  VIEW.  Perhaps  he  should  be 
sent  back  to  the  VIEW  menu  (whether  he  came  in  from  VIEW  or 
CREATE),  which  then  provides  the  option  of  either  looking  for  a 
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different  map,  or  exiting  to  the  main  menu. 

2)  -  In  VIEW,  it  is  assumed  that  the  LG  and  LM  commands  pass  into  the 
MP  sequence  when  a  particular  map  number  is  selected  (manual  sec- 
tipn  3.3.4,  and  7.4). 

3)  -  In  the  CREATE  sequence,  the  user  is  offered  the  option  to  type 

XX  TO  EXIT  THIS  SECTION  (manual  section  3.1.2), 
if  he  has  decided  he  does  not  want  to  proceed  with  the  map  previously 
selected  (section  3.1).  The  XX  command  does  not  exit  from  CREATE, 
as  expected,  but  instead  goes  to  the  VIEW  menu.  The  user  dialogue 
should  reflect  this  by  stating  instead: 

TYPE  "W"  TO  SEE  THE  AVAILABLE  MAPS. 

4)  -  Passage  of  control  when  the  user  exits  from  the  SAVE  command 
under  EXIT  (within  UPDATE)  is  not  clear  (section  5.11.2.1);  it  should  be 
back  to  the  main  menu. 

5)  —  There  is  an  inconsistency  in  the  wording  of  the  menu  options  for 
exiting  prematurely  from  DRAW  AIR  FORCE  SYMBOL.  DRAW  NAVAL  SYM- 

•  BOL  and  DRAW  GENERAL  SYMBOL  (sections  5.1.5,  5.1.6  and  5.1.7).  The 
terminology  used  is 
DRAW  NOTHING. 

whereas  the  preferred  terminology  used  at  other  similar  points  in  the 
dialogue  is 
EXIT. 


Alpha,  codes 

The  ,use  of  two  letter  codes  for  menu  items  is  not  the  preferred 
input  technique  (see  below  for  more  comments  on  this  issue).  If  this  technique 
is  used,  however,  research  carried  out  at  the  Army  Research  Institute  (Refer¬ 
ence  2)  indicates  that  the  codes  should  be  derived  by  simple  truncation  of  the 
full  word  being  abbreviated  (i.e.,  they  should  correspond  to  the  first  two 
letters  of  the  word).  ARI’s  experiments  showed  that  the  truncation  method  of 
abbreviation  was  consistently  preferred,  easily  decoded  and  frequently  used 
for  encoding  terms,  compared  to  abbreviations  based  on  contraction  or  con¬ 
traction  and  truncation.  These  findings  are  for  abbreviations  for  single  words. 
For  the  several  instances  in  the  Teletide  system  where  the  menu  option  con¬ 
sists  of  more  than  one  word,  it  is  recommended  that  the  first  letters  of  the 
first  two  words  be  used  as  an  abbreviation.  For  the  cases  where  truncation 
would  result  in  conflicts  in  the  menu  options  (e.g.,  DIRECTORY-DI  and 
DISPLAY-DI),  it  is  suggested  that  the  terminology  could  be  changed  (SHOW-SH 
for  DISPLAY). 


Menu,  format 


The  format  for  menu  presentation  varies  widely.  Most  of  the  menu 
frames  are  presented  with  the  coded  choice  to  the  right  of  the  item  (e.g., 
UPDATE,  section  5): 


DRAW  A  SYMBOL 

DR 

DELETE  A  SYMBOL 

DE 

MOVE  A  SYMBOL 

MO 

CHANGE  A  SYMBOL 

CH 

Most  of  the  menus  within  a  function  are  presented  in  the  form 
ft  s  (e.g.,  levels  of  units,  section  5. 1.4.2). 

However,  some  are  presented  in  a  list  in  the  form 

@@@@@@  ft  (e.g.,  airforce  symbol  types,  section  5.1.5), 
or  in  the  form 

@@@@@@@  .  ft  (e.g.,  background  maps,  section  3.3.4). 

The  choice  of  SIZE  OF  SYMBOL  is  presented  as 

SIZE  OF  SYMBOL  (1  =  SMALL.  2  =  MEDIUM,  3  =  LARGE) 
with  the  string  of  menu  items  in  brackets  (e.g.,  section  5. 1.4.3).  The  menu 
for  OWN/ENEMY  is  presented  in  a  similar  manner  with  alpha  rather  than 
numeric  codes. 

To  reduce  visual  scanning  by  the  user,  the  format  of  menu  presenta¬ 
tion  should  be  standardized.  It  is  recommended  that  main  menus  (ones  with 
two  letter  @@  input  codes)  be  presented  in  a  list  in  the  form 
.  ®®. 

Menus  offering  a  choice  of  symbol  attributes  should  be  presented  in  a  list  in 
the  form 

@@@@@@  .  ftft 

with  the  number  coding  starting  at  1  (not  0,  as  is  currently  the  case  for  the 
menu  for  LEVEL  OF  ARMY  UNIT  (section  5. 1.4. 2)). 

Similarly  there  is  wide  variation  in  the  style  in  which  user  input  is 
invited.  In  some  cases  the  command  line  inviting  user  input  occurs  before 
the  list  is  presented  (e.g.,  the  VIEW  menu);  in  others,  it  occurs  after  the  list 
(section  5.1.8,  naval  symbols).  In  some  instances  the  user  is  asked  to  ENTER, 
in  others  to  TYPE,  and  in  others  to  ANSWER.  In  some  cases,  the  appropriate 
user  input  is  enclosed  in  quotes  e.g., 

ENTER  "ZZ"  FOR  A  LIST  (section  12.1) 
or 

ENTER  "VV"  TO  VIEW  ...  (section  3); 

in  other  cases,  the  corresponding  codes  are  simply  listed  (e.g.,  section  5.4). 
It  is  recommended  that  the  options  available  at  each  stage  in  the  dialogue  be 
listed,  with  a  title,  followed  by  the  command  line  requesting  user  input  e.g., 
LEVEL  OF  UNIT? 

Where  this  is  not  possible  (e.g.,  when  a  yes/no  response  is  required),  the 
options  should  be  presented  in  brackets  after  the  question  e.g., 
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DO  YOU  WANT  RIVERS?  (YES  OR  NO). 

The  list  of  options  can  be  omitted  in  order  to  speed  up  the  dialogue  for  more 
sophisticated  users. 

Order  of  attribute  input 

The  order  of  attribute  input  for  symbol  DRAWing  (sections  5.1.4  to 
5.1.7)  should  be  standardized  as  much  as  possible.  The  following  order  is 
recommended:  TYPE  (input  first  since  it  is  one  of  the  most  important  attri¬ 
butes,  and  should  not  be  retained  in  short  term  memory  longer  than  neces¬ 
sary);  OWN/ENEMY;  either  EQUIVALENT  STRENGTH  (for  sections  5. 1.4.1  and 
5.1. 4.3),  or  NATIONALITY,  NUMERIC  DESIGNATION,  LEVEL  (for  section  5.1.4.2); 
and  finally  SYMBOL  SIZE,  followed  by  the  cursor  positioning  commands. 


Cursor  commands 


The  technique  for  cursor  movement  is  not  immediately  clear  to  a 
new  user.  The  following  dialogue  is  recommended: 


MOVE  CURSOR  TO  THE  DESIRED  POSITION  ON  THE  SCREEN. 
THEN  ENTER  A  CURSOR  COMMAND: 

S  =  THIS  IS  THE  POSITION  3  WANT 
X  =  CANCEL  THIS  OPERATION 


COMMAND? 

For  more  experienced  users,  this  dialogue  could  be  shortened  to 
POSITION? 


OWN /ENEMY  vs  COLOUR 

In  some  cases  the  user  is  asked  for  the  ownership  of  the  unit  which 
he  is  drawing  e.g., 

OWN/ENEMY  (section  5.1.4.1  to  5.1.4.3); 
in  other  cases,  the  same  question  is  posed  in  terms  of  the  COLOUR  (white, 
blue  or  red)  to  be  used  to  code  the  symbol  (e.g.,  section  5.1.5  to  5.1.7). 
Colour  is  being  used  here  to  code  information  of  operational  importance,  and 
the  user  dialogue  should  refer  to  the  information,  not  the  coding  technique 
The  information  should  be  requested  by  the  phrase 
OWN/ENEMY? 

In  cases  where  colour  is  not  used  as  a  code  (e.g.,  where  text  is  being  entered 
(sections  5.1.1  and  5.1.3)),  the  term  COLOUR  should  be  used  in  the  dialogue. 
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Symbol  size 

In  contrast  to  the  above  cases,  the  size  of  the  symbol  drawn  has  no 
operational  significance.  To  avoid  user  confusion  between  SIZE  and  some  other 
unit  attribute,  (like  STRENGTH),  specific  reference  should  be  made  to  SYMBOL 
SIZE  in  all  cases  where  the  size  of  the  symbol  can  be  chosen  by  the  user 
(e.g.,  most  functions  in  DRAW,  section  5.1.1  to  5.1.7). 


CAPITALS  vs  CITIES 

In  the  CREATE  and  VIEW  dialogues,  the  user  is  asked  whether  he 
wants  CAPITALS  (cities)  included  on  the  map.  In  the  EXIT  dialogue,  the  term 
CITIES  is  used.  The  latter  term  is  preferable. 


STANDARD  ARMY  SYMBOL 

One  menu  option  presented  in  section  5.1.4  is 
DRAW  STANDARD  ARMY  SYMBOL. 

The  word  ARMY  may  be  confusing  to  some  users,  since  it  does  not  refer  to  the 
level  of  the  unit,  as  do  the  other  choices  in  the  menu  (e.g.,  DRAW  BRIGADE 
EQUIVALENT  SYMBOL).  A  better  phrase  might  be 
DRAW  STANDARD  UNIT  SYMBOL. 


VIEW  function 

The  VIEW  function  (section  7)  is  difficult  to  understand,  partly 
because  of  the  wording  used  in  the  menu  and  for  the  display  titles.  A  more 
compact  presentation  may  be  desirable. 

1)  -  Combine  the  LG  and  LM  functions  into  a  single  function  (called  LM) 
similar  to  the  DIRECTORY  function.  The  user  would  have  the  option  of 
typing  LM  (to  get  the  region  list),  LM  @@  (to  get  maps  of  region  ®@) 
or  LM  ZZ  (to  get  all  maps). 

2)  -  Combine  the  DG,  RD  and  MP  functions  into  one  DISPLAY  MAP  (DM) 
function.  The  user  would  have  the  option  of  typing  DM  ##  to  get  a 
particular  map,  DM  @@  (to  see  the  geographical  regions),  -or  DM.  In 
the  latter  case,  the  user  would  then  be  presented  with  the  display  of 
geographic  regions,  and  asked  to  choose  one  for  further  display.  Upon 
input  of  @®,  the  maps  of  the  appropriate  region  would  be  displayed, 
and  the  user  would  be  asked  which  map  he  wanted  to  see.  See  Figure 
2  for  a  flowchart  describing  this  function  and  the  previous  one. 

3)  -  Change  the  titles  of  the  display  (described  in  sections  7.1  and  7.3) 
to  reflect  the  information  being  presented  to  the  user.  In  section  7.1, 
the  user  is  viewing  GEOGRAPHIC  REGIONS.  In  7.3,  he  is  viewing  MAPS 
IN  GEOGRAPHIC  REGION  @@. 
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ERASE/RECALL 

The  ERASE  command  (under  UPDATE)  can  only  be  invoked  after  ADD 
or  ATTACH.  Similarly,  the  RECALL  command  is  valid  only  after  DELETE.  To 
avoid  mistaken  usage  of  these  commands,  they  should  appear  in  the  UPDATE 
menu  only  when  their  use  is  valid,  not  all  the  time. 


EQUIVALENT  STRENGTH 

The  phrase  DIV/BGE  EQV  STRENGTH  is  used  in  both  dialogues  for 
DRAW  DIVISION  EQUIVALENT  (section  5. 1.4.1)  and  for  DRAW  BRIGADE 
EQUIVALENT  (section  5. 1.4.3).  The  wording  should  be  changed  to  reflect  the 
symbol  being  drawn  in  each  separate  case. 


AS  OF  TIME 

It  is  not  clear  what  the  user  must  type  to  input  the  AS  OF  TIME  (sec¬ 
tions  3.4  and  5.11.2).  The  example  given  shows  a  date-time  group  of  the  form 
2045  09  NOV  79,  whereas  the  manual  dictates  a  date-time  group  including 
hyphens  and  dashes. 


Abbreviations  in  Prompts 

The  use  of  abbreviations  should  be  restricted  to  those  that  are  well- 
known  to  the  user.  It  is  recommended  that  EQV  (used  in  section  5.1.4. 1)  and 
EQUIV  (section  5. 1.4.3)  be  expanded  to  the  full  word  EQUIVALENT.  Similarly 
BG  in  the  main  menu  should  be  expanded  to  BACKGROUND. 


Feedback 

It  is  desirable  to  have  more  feedback  about  the  status  of  overlays 
and  updates,  particularly  when  the  user  has  cancelled  or  exited  prematurely 
from  a  function.  Such  feedback  helps  to  build  user  confidence  in  the  system. 
Teletide  designers  mentioned  that  it  might  be  helpful  to  the  user  to  have  an 
indication  of  the  menu  level  at  each  stage  of  interaction  e.g., 

UU/DR/UB  (the  user  is  drawing  unit  boundaries  under  UPDATE). 

We  concur,  and  feel  that  such  a  feature  will  help  reduce  the  impression  that 
users  of  large  menu  systems  often  have  of  being  "lost  in  the  maze". 
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ENHANCEMENTS 


Levels  of  Dialogue 

One  of  the  problems  in  man-computer  interaction  is  to  provide  an 
interface  that  accommodates  the  training  and  experience  of  a  variety  of 
users.  New  users  of  a  system  are  often  intimidated  by  the  succinct  requests 
(and  error  messages)  which  are  presented  by  the  computer,  whereas  more 
experienced  users  often  feel  their  interaction  is  being  hampered  by  verbose 
dialogues,  feedback  and  examples  at  every  stage.  One  solution  to  this  prob¬ 
lem  is  to  provide  different  levels  of  dialogue  for  users  of  different  sophistica¬ 
tion.  The  designers  of  the  Teletide  system  have  already  incorporated  this 
suggestion  to  a  degree  by  providing  direct  and  indirect  commands  at  the 
main  menu  level,  and  by  allowing  several  menu  selections  to  be  input  in  a  sin¬ 
gle  command  string.  However,  it  is  recommended  that  this  feature  be 
extended  by  providing  three  levels  of  dialogue  for  the  user,  and  permitting 
him  to  choose  the  level  he  prefers. 

Level  1,  designed  for  new  users,  would  provide  a  verbose  interface, 
which  guides  the  user  step-by-step  by  providing  instruction  and  lots  of  exam¬ 
ples.  Pages  of  text  introducing  the  system  to  the  user  would  reside  at  this 
level.  There  should  be  extensive  feedback  at  each  step  to  indicate  where  the 
user  sits  in  the  menu  system.  This  level  should,  in  fact,  act  as  an  on-line 
tutorial  and  review  of  system  use. 

Level  2  would  be  the  working  dialogue  for  the  majority  of  users.  It 
would  essentially  be  the  same  as  the  dialogue  described  in  the  current  system 
manual.  Users  should  be  able  to  get  more  help  at  any  point  in  the  dialogue 
by  typing  HELP  for  instructions,  or  EG  for  an  example  of  the  appropriate 
input  at  that  stage. 

Level  3  is  for  frequent  system  users  who  will  accept  a  very  sparse 
dialogue  to  speed  up  the  interaction.  For  such  users,  the  menu  lists  may  be 
omitted  and  the  information  requested  in  a  short  phrase  e.g., 

SIZE  OF  SYMBOL? 

This  level  of  user  should  be  permitted  to  see  the  appropriate  menu  at  any 
stage  in  the  dialogue  if  he  hits  RETURN  without  a  menu  selection.  Appendix  A 
presents  sample  dialogues  for  the  three  levels  for  the  dialogue  of  section 
5. 1.4.1. 
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Tutorial 


In  addition  to  the  inclusion  of  a  tutorial  level  of  user  dialogue  in  the 
Teletide  system,  it  is  recommended  that  a  separate  tutorial  package  be  pro¬ 
vided  for  the  new  user.  The  package  should  include  a  set  of  pre-generated 
display  pages  and  a  series  of  sample  problems  designed  to  familiarize  him 
with  all  parts  of  the  system.  This  will  not  only  provide  an  environment  for 
directed  learning,  but  will  allow  the  user  to  experiment  with  the  commands 
offered  in  the  Teletide  system  without  fear  of  compromising  the  information  in 
the  display  pages  used  for  normal  SHAPE  HQ  operations. 


Text  Editors 

It  would  be  preferable  if  the  two  text  editors  in  Teletide  (one  in  the 
DRAW  function  and  one  in  UPDATE)  could  be  combined  into  one,  but  remain 
available  under  both  functions  in  the  system.  This  would  eliminate  the 
current  problem  of  being  able  to  modify  text  using  only  the  editor  in  which  it 
was  created. 

DCIEM  found  the  new  text  editor  rather  difficult  to  use,  partly 
because  the  the  two  letter  codes  for  editing  commands  are  prefaced  with  the 
escape  character.  The  editing  sequence  is  slow  because  the  user  is  continu¬ 
ally  looking  from  screen  to  screen  for  feedback  as  he  types  in  the  command 
string  and  then  checks  to  ensure  that  it  has  had  the  effect  he  wanted.  The 
fact  that  the  keyboard  is  used  both  as  a  device  for  typing  text  onto  the 
screen,  and  as  a  device  for  manipulating  that  text  means  that  there  is  not  a 
clear  separation  of  these  functions  for  the  user.  An  alternative  to  the  typed 
editing  commands  is  to  provide  function  keys  which  insert  and  delete  lines 
and  characters.  A  good  example  of  these  function  buttons  is  found  on  the 
Hewlett-Packard  2645  graphics  terminal.  The  keys  operate  as  follows: 

Insert  line  -  A  blank  line  is  inserted  above  the  line  currently  pointed 
to  by  the  cursor  and  the  cursor  is  sent  to  the  beginning  of  the  new 
line. 

Delete  line  -  The  current  line  is  deleted  and  the  cursor  is  sent  to  the 
beginning  of  the  following  line. 

Insert  character  -  All  characters  typed  after  this  button  is  pushed 
will  be  inserted  ahead  of  the  current  cursor  position.  A  small  light 
tells  the  user  that  he  is  in  this  mode.  To  get  out  of  the  insert  char¬ 
acter  mode,  the  user  depresses  the  button  again,  and  the  light  goes 
out.  Characters  typed  on  the  screen  will  then  replace  those  already 
there. 

Delete  character  -  The  character  indicated  by  the  cursor  is  deleted 
and  the  remaining  text  is  moved  left  to  fill  the  gap. 

The  functions  for  inserting  and  deleting  lines  and  deleting  characters  will 
repeat  as  long  as  the  appropriate  button  is  depressed.  Such  a  mode  of 
interaction  could  be  implemented  by  software  on  a  graphics  terminal  with  a 
conventional  keyboard. 
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INTERACTION  TECHNIQUE 


Man-computer  interfaces  should  permit  interaction  that  is  fluid  and 
easy,  and  that  take  place  as  fast  as  the  user  desires.  The  typed  input  tech¬ 
nique  used  in  the  Teletide  system  is  slow,  even  for  a  new  user.  Interaction 
through  a  keyboard  is  particularly  cumbersome  when  the  user  wishes  to  place 
symbols  on  a  map,  or  update  the  symbols,  especially  if  the  information  is 
being  dictated  verbally.  A  two-letter  input  code  is  required  by  the  system  to 
reduce  errors  in  menu  item  selection.  However,  some  of  the  codes  employ  two 
identical  letters.  This  should  be  avoided;  if  the  first  letter  was  an  error,  the 
requirement  to  simply  repeat  it  gives  no  opportunity  for  second  thought.  In 
any  case,  other  input  techniques  could  be  used  to  minimize  menu  selection 
errors.  For  example,  provision  should  be  made  for  the  user  to  change  his 
mind  about  an  input  if  he  realizes  a  mistake  has  been  made,  by  allowing  him 
to  back  up  in  the  input  sequence  to  correct  his  error. 

Probably  the  fastest  interface  for  systems  such  as  Teletide  is  one 
which  is  voice-driven.  Voice-driven  input  is  probably  more  accurate  than 
typed  input,  although  suitable  feedback  must  be  provided  to  the  user.  This 
can  be  done  visually,  or  by  voice  synthesis.  Automatic  speech  recognition  is  a 
field  that  is  being  intensively  investigated,  and  many  systems  are  in  use 
world-wide.  Prices  for  useful  systems  range  from  $2,500  for  an  Interstate  sys¬ 
tem  with  3%  error  in  recognition  (based  on  a  20  word  vocabulary)  to  $65,000 
for  a  Verbex  system  with  0.2%  error  in  recognition.  These  error  rates  were 
obtained  in  controlled  laboratory  conditions,  but  comparable  rates  should  be 
attained  by  trained  and  motivated  operators  in  the  field.  DCIEM  is  interested 
in  doing  studies  of  man-computer  interaction  using  voice-driven  menu  sys¬ 
tems,  although  at  present  it  has  no  suitable  equipment. 

An  alternative  would  be  a  cursor-driven  menu  system,  where  instead 
of  typing  an  alpha  or  numeric  code  for  menu  items,  the  user  selects  it  using 
a  cursor  driven  by  a  rollball  or  tablet.  Use  of  a  keyboard  is  necessary  only 
when  a  label  such  as  a  display  page  title  or  date-time  group  must  be  entered. 
We  speculate  that  such  an  interface  would  be  faster  than  the  current  typed 
interaction,  at  least  for  non-expert  users.  DCIEM  intends  to  investigate  the 
issue  further  by  carrying  out  a  small  experiment  to  compare  menu  selection 
using  typed  codes  vs  cursor-driven  item  selection.  We  will  use  the  menus  of 
the  Teletide  system  as  the  stimulus  material  and  include  menu  familiarity  and 
learning  as  factors  by  investigating  performance  over  several  experimental 
sessions. 
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MAP  MANIPULATION 


One  unique  feature  of  the  Teletide  system  is  the  provision  of  a  set  of 
simple  computer-generated  maps  which  have  been  derived  from  the  World 
Data  Bank  cartographic  data  set.  Generally  these  maps  are  satisfactory  for 
most  of  the  fairly  static  situation  displays  used  in  briefings,  but  the  military 
user  has  expressed  an  interest  in  being  able  to  generate  maps  in  real  time 
for  any  segment  of  the  world,  at  a  range  of  scales.  He  will  therefore  need  to 
interact  more  directly  with  the  cartographic  data  base,  and  will  eventually 
need  the  facility  to  scroll  the  map  display  and  zoom  in  on  certain  regions. 
Investigations  of  zooming  and  scrolling  are  currently  being  carried  out  as  part 
of  DCIEM's  experimental  program  in  computer-based  map  interaction. 

The  present  Teletide  system  does  not  provide  any  link  between  the 
background  map  and  the  overlaid  military  information.  In  other  words,  the 
user  cannot  ask  the  system  to  give  distances  between  military  units  and  cities 
or  to  do  more  sophisticated  problem-solving  such  as  planning  a  route  for 
equipment  movement  in  a  logistics  operation.  Before  this  capability  and  the 
capability  to  generate  maps  "on  the  fly"  can  be  provided,  suitable  ways  must 
be  found  to  structure  the  cartographic  data  to  allow  fast  access  and  manipu¬ 
lation  of  it.  Such  techniques  are  now  being  investigated  in  a  DCIEM  contract 
for  design  of  an  Interactive  Spatial  Information  System  (ISIS). 

Another  issue  is  the  question  of  how  much  map  information  is 
required  for  the  user  to  orient  himself  on  a  particular  map.  Teletide  system 
designers  have  guessed  that  river  and  major  cities,  at  minimum,  are  required 
but  expressed  concern  that  there  were  no  research  findings  to  guide  them  on 
this  issue.  The  problem  becomes  more  complicated  if  the  military  operation 
is  in  a  remote  part  of  the  world  where  there  are  few,  if  any,  instances  of  the 
default  map  features  (e.g.,  the  Sahara  desert).  This  is  a  problem  that  will 
receive  research  attention  at  DCIEM.  The  ISIS  system  is  intended  to  permit 
the  display  of  situationally  relevant  features  at  appropriate  scales. 
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APPENDIX  A 

SUGGESTED  DIALOGUE  FOR  THREE  LEVELS  OF  USER 
(UPDATE/DRAW/LAND  FORCES/DIVISION  EQUIVALENT,  section  5. 1.4.1) 


LEVEL  1: 

YOU  HAVE  CHOSEN  TO 
DRAW  A  DIVISION 
EQUIVALENT  SYMBOL. 

'THESE  ARE  THE 
CODES  FOR 
OWNER  OF  UNIT: 

OWN  .  1 

ENEMY  2 

NEUTRAL  ..  3 

CHOOSE  THE  APPRO¬ 
PRIATE  CODE  AND 
ENTER  OWNER:  1 

DIVISION  EQUIVALENT 
STRENGTH  IS  INPUT  AS 
A  STRING  OF  NUMERALS 
E.G.,  12  2/3. 

THE  MAXIMUM  LENGTH  IS 

[ - ]. 

ENTER  DIVISION 
EQUIVALENT  STRENGTH: 

[ - ] 

4 

THESE  ARE  THE  CODES 

FOR  THE 

SIZE  OF  SYMBOL- 

SMALL  1 

MEDIUM  ...  2 
LARGE  3 

CHOOSE  THE  APPRO¬ 
PRIATE  CODE  AND 
ENTER  SIZE:  1 


LEVEL  2: 

OWNER  OF  UNIT: 

OWN  .  1 

ENEMY  2 

NEUTRAL  ..  3 

ENTER  OWNER:  1 

ENTER  DIVISION 
EQUIVALENT  STRENGTH: 
4 


SIZE  OF  SYMBOL: 

SMALL .  1 

MEDIUM  ...  2 
LARGE  .  3 

ENTER  SIZE:  1 


ENTER  COMMAND:  S 


LEVEL  3: 

OWNER?  1 

DIVISION  EQUIVALENT 
STRENGTH?  4 

SIZE  OF  SYMBOL?  1 

POSITION?  S 


INDICATE  POSITION. 

CURSOR  COMMANDS  ARE: 

S=  THIS  IS  THE  POSITION  I  WANT 
X=  CANCEL  THIS  OPERATION 


INDICATE  THE  POSITION 
OF  THE  SYMBOL  ON  THE 
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DISPLAY  SCREEN. 

USE  THE  FUNCTION  BUTTONS 
TO  MOVE  THE  CURSOR  TO  THE 
DESIRED  POSITION  ON  THE 
SCREEN.  THEN  ENTER  A 
CURSOR  COMMAND: 

S=  THIS  IS  THE  POSITION  I  WANT 
X=  CANCEL  THIS  OPERATION 

ENTER  COMMAND:  S 


I 


